Class KRATool
java.lang.Object
com.netscape.cmstools.KRATool
Note: See Cross-Scheme Migration Support below for new features
The KRATool class is a utility program designed to operate on an LDIF file
to perform one or more of the following tasks:
(A) Use a new storage key (e. g. - a 2048-bit key to replace a
1024-bit key) to rewrap the existing triple DES symmetric key
that was used to wrap a user's private key.
STARTING INVENTORY:
(1) a KRATOOL configuration file containing KRA LDIF record
types and the processing status of their associated fields
(2) an LDIF file containing 'exported' KRA data
(referred to as the "source" KRA)
NOTE: If this LDIF file contains data that was originally
from a KRA instance that was prior to RHCS 8, it
must have previously undergone the appropriate
migration steps.
(3) the NSS security databases associated with the data
contained in the source LDIF file
NOTE: If the storage key was located on an HSM, then the
HSM must be available to the machine on which the
KRATool is being executed (since the RSA private
storage key is required for unwrapping the
symmetric triple DES key). Additionally, a
password may be required to unlock access to
this key (e. g. - which may be located in
the source KRA's 'password.conf' file).
(4) a file containing the ASCII BASE-64 storage certificate
from the KRA instance for which the output LDIF file is
intended (referred to as the "target")
ENDING INVENTORY:
(1) all items listed in the STARTING INVENTORY (unchanged)
(2) a log file containing information suitable for audit
purposes
(3) an LDIF file containing the revised data suitable for
'import' into a new KRA (referred to as the "target" KRA)
KRATool PARAMETERS:
(1) the name of the KRATOOL configuration file containing
KRA LDIF record types and the processing status of their
associated fields
(2) the name of the input LDIF file containing data which was
'exported' from the source KRA instance
(3) the name of the output LDIF file intended to contain the
revised data suitable for 'import' to a target KRA instance
(4) the name of the log file that may be used for auditing
purposes
(5) the path to the security databases that were used by
the source KRA instance
(6) the name of the token that was used by
the source KRA instance
(7) the name of the storage certificate that was used by
the source KRA instance
(8) the name of the file containing the ASCII BASE-64 storage
certificate from the target KRA instance for which the
output LDIF file is intended
(9) OPTIONALLY, the name of a file which ONLY contains the
password needed to access the source KRA instance's
security databases
(10) OPTIONALLY, choose to change the specified source KRA naming
context to the specified target KRA naming context
(11) OPTIONALLY, choose to ONLY process CA enrollment requests,
CA recovery requests, CA key records, TPS netkeyKeygen
enrollment requests, TPS recovery requests, and
TPS key records
DATA FIELDS AFFECTED (using default config file values):
(1) CA KRA enrollment request
(a) dateOfModify
(b) extdata-requestnotes
(2) CA KRA key record
(a) dateOfModify
(b) privateKeyData
(3) CA KRA recovery request
(a) dateOfModify
(b) extdata-requestnotes (NEW)
(4) TPS KRA netkeyKeygen (enrollment) request
(a) dateOfModify
(b) extdata-requestnotes (NEW)
(5) TPS KRA key record
(a) dateOfModify
(b) privateKeyData
(6) TPS KRA recovery request
(a) dateOfModify
(b) extdata-requestnotes (NEW)
(B) Specify an ID offset to append to existing numeric data
(e. g. - to renumber data for use in KRA consolidation efforts).
STARTING INVENTORY:
(1) a KRATOOL configuration file containing KRA LDIF record
types and the processing status of their associated fields
(2) an LDIF file containing 'exported' KRA data
(referred to as the "source" KRA)
NOTE: If this LDIF file contains data that was originally
from a KRA instance that was prior to RHCS 8, it
must have previously undergone the appropriate
migration steps.
ENDING INVENTORY:
(1) all items listed in the STARTING INVENTORY (unchanged)
(2) a log file containing information suitable for audit
purposes
(3) an LDIF file containing the revised data suitable for
'import' into a new KRA (referred to as the "target" KRA)
KRATool PARAMETERS:
(1) the name of the KRATOOL configuration file containing
KRA LDIF record types and the processing status of their
associated fields
(2) the name of the input LDIF file containing data which was
'exported' from the source KRA instance
(3) the name of the output LDIF file intended to contain the
revised data suitable for 'import' to a target KRA instance
(4) the name of the log file that may be used for auditing
purposes
(5) a large numeric ID offset (mask) to be appended to existing
numeric data in the source KRA instance's LDIF file
(6) OPTIONALLY, choose to change the specified source KRA naming
context to the specified target KRA naming context
(7) OPTIONALLY, choose to ONLY process CA enrollment requests,
CA recovery requests, CA key records, TPS netkeyKeygen
enrollment requests, TPS recovery requests, and
TPS key records
DATA FIELDS AFFECTED (using default config file values):
(1) CA KRA enrollment request
(a) cn
(b) dateOfModify
(c) extdata-keyrecord
(d) extdata-requestnotes
(e) requestId
(2) CA KRA key record
(a) cn
(b) dateOfModify
(c) serialno
(3) CA KRA recovery request
(a) cn
(b) dateOfModify
(c) extdata-requestid
(d) extdata-requestnotes (NEW)
(e) extdata-serialnumber
(f) requestId
(4) TPS KRA netkeyKeygen (enrollment) request
(a) cn
(b) dateOfModify
(c) extdata-keyrecord
(d) extdata-requestid
(e) extdata-requestnotes (NEW)
(f) requestId
(5) TPS KRA key record
(a) cn
(b) dateOfModify
(c) serialno
(6) TPS KRA recovery request
(a) cn
(b) dateOfModify
(c) extdata-requestid
(d) extdata-requestnotes (NEW)
(e) extdata-serialnumber
(f) requestId
(C) Specify an ID offset to be removed from existing numeric data
(e. g. - to undo renumbering used in KRA consolidation efforts).
STARTING INVENTORY:
(1) a KRATOOL configuration file containing KRA LDIF record
types and the processing status of their associated fields
(2) an LDIF file containing 'exported' KRA data
(referred to as the "source" KRA)
NOTE: If this LDIF file contains data that was originally
from a KRA instance that was prior to RHCS 8, it
must have previously undergone the appropriate
migration steps.
ENDING INVENTORY:
(1) all items listed in the STARTING INVENTORY (unchanged)
(2) a log file containing information suitable for audit
purposes
(3) an LDIF file containing the revised data suitable for
'import' into a new KRA (referred to as the "target" KRA)
KRATool PARAMETERS:
(1) the name of the KRATOOL configuration file containing
KRA LDIF record types and the processing status of their
associated fields
(2) the name of the input LDIF file containing data which was
'exported' from the source KRA instance
(3) the name of the output LDIF file intended to contain the
revised data suitable for 'import' to a target KRA instance
(4) the name of the log file that may be used for auditing
purposes
(5) a large numeric ID offset (mask) to be removed from existing
numeric data in the source KRA instance's LDIF file
(6) OPTIONALLY, choose to change the specified source KRA naming
context to the specified target KRA naming context
(7) OPTIONALLY, choose to ONLY process CA enrollment requests,
CA recovery requests, CA key records, TPS netkeyKeygen
enrollment requests, TPS recovery requests, and
TPS key records
DATA FIELDS AFFECTED (using default config file values):
(1) CA KRA enrollment request
(a) cn
(b) dateOfModify
(c) extdata-keyrecord
(d) extdata-requestnotes
(e) requestId
(2) CA KRA key record
(a) cn
(b) dateOfModify
(c) serialno
(3) CA KRA recovery request
(a) cn
(b) dateOfModify
(c) extdata-requestid
(d) extdata-requestnotes (NEW)
(e) extdata-serialnumber
(f) requestId
(4) TPS KRA netkeyKeygen (enrollment) request
(a) cn
(b) dateOfModify
(c) extdata-keyrecord
(d) extdata-requestid
(e) extdata-requestnotes (NEW)
(f) requestId
(5) TPS KRA key record
(a) cn
(b) dateOfModify
(c) serialno
(6) TPS KRA recovery request
(a) cn
(b) dateOfModify
(c) extdata-requestid
(d) extdata-requestnotes (NEW)
(e) extdata-serialnumber
(f) requestId
KRATool may be invoked as follows:
KRATool
-kratool_config_file <path + kratool config file>
-source_ldif_file <path + source ldif file>
-target_ldif_file <path + target ldif file>
-log_file <path + log file>
[-source_pki_security_database_path <path to PKI source database>]
[-source_storage_token_name '<source token>']
[-source_storage_certificate_nickname '<source nickname>']
[-target_storage_certificate_file <path to target certificate file>]
[-source_pki_security_database_pwdfile <path to PKI password file>]
[-append_id_offset <numeric offset>]
[-remove_id_offset <numeric offset>]
[-source_kra_naming_context '<original source KRA naming context>']
[-target_kra_naming_context '<renamed target KRA naming context>']
[-process_requests_and_key_records_only]
where the following options are 'Mandatory':
-kratool_config_file <path + kratool config file>
-source_ldif_file <path + source ldif file>
-target_ldif_file <path + target ldif file>
-log_file <path + log file>
AND at least ONE of the following are a 'Mandatory' set of options:
(a) options for using a new storage key for rewrapping:
[-source_pki_security_database_path
<path to PKI source database>]
[-source_storage_token_name '<source token>']
[-source_storage_certificate_nickname '<source nickname>']
[-target_storage_certificate_file
<path to target certificate file>]
AND OPTIONALLY, specify the name of a file which ONLY contains
the password needed to access the source KRA instance's
security databases:
[-source_pki_security_database_pwdfile
<path to PKI password file>]
AND OPTIONALLY, rename source KRA naming context --> target
KRA naming context:
[-source_kra_naming_context '<source KRA naming context>']
[-target_kra_naming_context '<target KRA naming context>']
AND OPTIONALLY, process requests and key records ONLY:
[-process_requests_and_key_records_only]
(b) option for appending the specified numeric ID offset
to existing numerical data:
[-append_id_offset <numeric offset>]
AND OPTIONALLY, rename source KRA naming context --> target
KRA naming context:
[-source_kra_naming_context '<source KRA naming context>']
[-target_kra_naming_context '<target KRA naming context>']
AND OPTIONALLY, process requests and key records ONLY:
[-process_requests_and_key_records_only]
(c) option for removing the specified numeric ID offset
from existing numerical data:
AND OPTIONALLY, rename source KRA naming context --> target
KRA naming context:
[-source_kra_naming_context '<source KRA naming context>']
[-target_kra_naming_context '<target KRA naming context>']
[-remove_id_offset <numeric offset>]
AND OPTIONALLY, process requests and key records ONLY:
[-process_requests_and_key_records_only]
(d) (a) rewrap AND (b) append ID offset
[AND OPTIONALLY, rename source KRA naming context --> target
KRA naming context]
[AND OPTIONALLY process requests and key records ONLY]
(e) (a) rewrap AND (c) remove ID offset
[AND OPTIONALLY, rename source KRA naming context --> target
KRA naming context]
[AND OPTIONALLY process requests and key records ONLY]
NOTE: Options (b) and (c) are mutually exclusive!
Cross-Scheme Migration Support
KRATool supports cross-scheme migration, enabling secure migration of archived keys between KRA instances using different cryptographic schemes (e.g., from RSA+AES/CBC to RSA-OAEP+AES-KWP for FIPS-mode HSMs).
Key Features:
- Secure rewrap flow: Private keys remain wrapped in tokens throughout the migration process.
- Order-independent LDIF parsing: Extracts privateKeyData and publicKeyData fields independently, regardless of their order in LDIF records.
- Algorithm auto-detection: Automatically regenerates session keys only when source and target algorithms or key sizes differ.
- HSM compatibility: Supports private key payload processing in NSS DB (software token) via -use_nss_for_payload_processing flag when HSM lacks support for source or target algorithms.
- Pure Java implementation: When -use_nss_for_payload_processing is used, the importSessionKeyToToken() method implements JSS_KeyExchange mechanism in pure Java with automatic fallback to temporary RSA keypair approach.
Supported Algorithms:
- Session key wrap: RSA, RSA-OAEP
- Payload wrap: AES KeyWrap/Wrapped (CKM_AES_KEY_WRAP_KWP, recommended for HSM/FIPS), AES KeyWrap/Padding (CKM_AES_KEY_WRAP_PAD), AES KeyWrap/NoPadding (CKM_AES_KEY_WRAP), AES/CBC/PKCS5Padding, DES3/CBC/Padding
Cross-Scheme Command-Line Options:
-source_rsa_wrap_algorithm <RSA|RSA-OAEP>
Source session key wrap algorithm (default: RSA)
-target_rsa_wrap_algorithm <RSA|RSA-OAEP>
Target session key wrap algorithm (default: RSA-OAEP, recommended for HSM/FIPS)
-source_payload_wrap_algorithm <algorithm>
Source payload wrap algorithm (must match source KRA's payloadWrapAlgorithm)
Supported: "AES KeyWrap/Wrapped" - CKM_AES_KEY_WRAP_KWP (0x210B) (recommended)
"AES KeyWrap/Padding" - CKM_AES_KEY_WRAP_PAD (0x210A)
"AES KeyWrap/NoPadding" - CKM_AES_KEY_WRAP (0x2109)
"AES/CBC/PKCS5Padding", "DES3/CBC/Padding"
-target_payload_wrap_algorithm <algorithm>
Target payload wrap algorithm (must match target KRA's configured algorithm)
Supported: "AES KeyWrap/Wrapped" - CKM_AES_KEY_WRAP_KWP (0x210B) (recommended)
"AES KeyWrap/Padding" - CKM_AES_KEY_WRAP_PAD (0x210A)
"AES KeyWrap/NoPadding" - CKM_AES_KEY_WRAP (0x2109)
"AES/CBC/PKCS5Padding", "DES3/CBC/Padding"
-source_payload_wrap_keysize <128|192|256>
Source payload wrapping key size in bits (default: 128)
-target_payload_wrap_keysize <128|192|256>
Target payload wrapping key size in bits (default: 128)
-use_nss_for_payload_processing
Perform payload unwrap/rewrap in NSS DB (software token) when HSM lacks
support for target algorithms
-regenerate_session_key
Force regeneration of session key even when algorithms match
-split_target_ldif_per_records <N>
Split output into multiple LDIF files, each containing N records
-verbose
Enable detailed per-record logging (useful for debugging)
-use_oaep_rsa_key_wrap
Use RSA-OAEP instead of RSA PKCS#1 v1.5 (legacy flag)
- Author:
- mharmsen, cfu (added cross-scheme migration support)
-
Field Summary
Fields -
Constructor Summary
Constructors -
Method Summary
-
Field Details
-
logger
public static org.slf4j.Logger logger
-
-
Constructor Details
-
KRATool
public KRATool()
-
-
Method Details
-
main
-